Concord Consortium currently uses Java Web Start to deploy its Java applications to students in all its projects. Web Start makes it easy for end users to download the compiled Java code and run an application, and to update their code as new releases are made available.

By default, Web Start stores all the downloaded code into a folder in the user's home folder, e.g. /Users/<username>/Library/Caches/Java. This default makes it easy for users with limited administrative rights to install a Java application and use it.

However, this default has several major drawbacks that may be a problem in schools:

• Since the files must be in the user's home folder, it may be very difficult for an application to be easily deployed, as an administrator may not be able pre-load the Java cache with the compiled code. This means that individual students must download/install the software themselves, which can be very time consuming in a classroom setting.
• Each student will need to download/install the software once, even if the software has already been used on a specific computer.
• If students have a disk quota, the large size of the install (100 MB+) may be very problematic.
• If the student's home folders are networked and are stored on a school server, the synchronization with the server may be taxing for the school's network.

To solve these problems, one alternative is to change the Web Start settings so that the files are saved and read from a folder on the local computer. This requires two steps:

1. Setting Web Start to cache files in a different folder
2. Ensuring that students have permission to read and write from all files that exist and may be created in that folder.

Changing the Web Start cache location

A system properties file will need to be created which changes the location of the Web Start cache, and configuration file will need to be created which points to that system properties file.

If it does not already exist, a file deployment.config needs to be created in the deployment system home. The deployment system home on Mac OS X is /System/Library/Frameworks/JavaVM.framework/Home/ and on Windows is in <Windows Directory>\Sun\Java\Deployment.

The deployment.config file needs to set the location of a new file, deployment.properties. This properties file can be in the same folder as the deployment.config file. To set this location, the config must contain the line: deployment.system.config=file://path/to/deployment.properties

An example deployment.config class may therefore be as follows:

The file deployment.properties should now be written the location specified, and should indicate the new desired location of the Java Web Start cache. To do this, it must contain the line: deployment.user.cachedir=/path/to/webstart/cache.

An example deploy.properties class may therefore be as follows:

Testing

You can test that this configuration change has been correctly applied by trying our Java Checker application, which you can run by clicking on http://jnlp.concord.org/dev/org/concord/maven-jnlp/java-checker/java-checker.jnlp.

When this runs you should notice two things:

1. New files have been downloaded to the newly-created Web Start cache folder you selected,
2. The property deployment.user.cachedir printed out in the window should point to the cache folder you selected.

Ensuring that students have read/write permissions on the new folder

In order for students to be able to run the software and automatically update the software if new versions are released, the students need to have full permissions on the new Web Start cache folder. They not only need full permissions for all files and folders that may currently exist on the folder, but also for any files and folders that another user may create in the future.

One way to grant these permissions would be to include a script as a login hook which automatically granted full permissions recursively on all files and folders in the cache folder.

A second, possibly cleaner way, is to use ACLs (Access Control Lists), and set them up on the cache folder so that the permissions are inherited down to all sub folders.

Using ACLs

ACLs have been available to Macs since OS X 10.4. ACLs need to be turned on before they can be used. To turn them on run:

or, on Mac OS X Server, you can use the Workgroup Manager.

We can apply ACLs so that users have all necessary permissions on the cache folder:

First remove all existing ACLs:

Now setup the root ACL:

Now apply the rule to all the existing files:

Testing

To see if ACLs applied the permissions as expected, check the permissions of the webstart cache, and then create a file and check the permissions on that file:

e.g.

You can also test this by running one version of Concord software as one member of some_group, and then running a different version of the software as another. The first user should be able to successfully write files to the cache location, and the second should be able to read those files and add new files.

Two examples of software that could be used by two managed users are a UDL activity and an ITSI activity. The first application will add ~130 MB, and the second will add a few more MBs.